The thing is that with tens of thousands of stored records the current internal Airio arrangement eats quite a lot of memory, because everything's always held in memory. For example Airio managing AirAttack demo servers can take over 100 MB of system memory. With so many records the delay when enumerating through data starts to be noticeable. While it is usually not a big problem, there are other considerations such as data integrity and code simplifications.
What I'm now trying to do is keep all the data in a database, using relatively simple queries to select what needs to be shown or insert/update what needs to be changed. Database also simplifies/enables external changes to the data, at least for everyone knowing SQL basics. For all this I need a database engine with specific properties. It needs to be simple, fast, portable, easily configurable.
SQLite has these properties. It is just one DLL file, no setup and configuration is necessary. The created database is in just one file, perfectly portable. There's no chance using MySQL as the primary data store, because 9 or 10 Airio users would fail miserably installing and configuring the system. (Count me among them.) SQLite support in Airio requires just one external file and that's it.
I'm afraid using MySQL as the primary data store is not possible. The question is if a sort of export to MySQL could be implemented, but I'm really not sure...
Aaaah, very good point (as always)! The journal file is not important, but the DB3 file should go to the daily backups. I'll see what can be done and will try to implement the functionality into almost finished Airio 2.4.5...
Yes, me too, and I'd like to extend SQLite support soon, making it primary data storage first and then replace all the in-memory hashtables by SQLite queries. In the meantime I'd appreciate if more people tried to install the SQLite support so that I'm sure the basic code is OK.
Important bug note
Hello Airio users, I'm very sorry to announce this, but please DO NOT USE AIRIO version 2.4.3, FREE nor FULL/PROS. It contains a very serious bug that causes in certain not quite rare cases wrong stats to be saved, which are then hard to get rid of.
An update is ready, version 2.4.4, but unfortunately the airio.eu site is now out order for several hours, so I cannot upload the update and change links. I'll do this all as soon as possible. Updated version is already sent to 500servers, hopefully it will be available soon.
Sorry for this bug. It concerns stats "optimization" done when implementing initial SQLite support. Well, this optimization was not quite optimal. :doh::doh::doh::doh::doh::doh:
An update is ready, version 2.4.4, but unfortunately the airio.eu site is now out order for several hours, so I cannot upload the update and change links. I'll do this all as soon as possible. Updated version is already sent to 500servers, hopefully it will be available soon.
Sorry for this bug. It concerns stats "optimization" done when implementing initial SQLite support. Well, this optimization was not quite optimal. :doh::doh::doh::doh::doh::doh:
Such things always depend on configuration, usually items in the TCD file specifying track/car data and items in SRV file enabling specific checks. But the simplest solution: 1) If you're spectated/kicked because of impossible speed, set CheckSpeed in SRV file to false. 2) If you're kicked because of impossible split/lap time (which may happen on oval using draft), set CheckTime in SRV file to false.
There's no relation between !car and !del commands, try just !del xrg system shock while SO5R is loaded.
Indeed !delete it is. The half move to SQLite (with the intention of full implementation) is intended exactly for these kinds of situations. Instead of having to implement all kinds of special commands admins could perform any query on the database with immediate impact. Also viewing current data in a SQLite tool would be much more user-friendly than the custom TXT files...
Yes indeed, they are very incorrectly restored session data. Mannef1 disconnected shortly before track rotation and reconnected shortly after. The bug is corrected now, it concerns only FULL/PROS versions, update is available and it is a must for all admins with busy servers and track rotations.
Woo, that is a nasty one bug... And soooo hard to track down. But I'm asking Dave now about logs and will try to solve it immediately.
Airio 2.4.3
New Airio version is released. Apart from some corrections and smaller updates (as you can read in the changelog) it adds experimental SQLite support, for now only in the FULL/PROS version. Currently import of all Airio data into the database is made if no database if found on Airio restart or when the !dbi command is used by an admin with stats update rights. When the database is created/found, it is updated separately from main Airio stats, but it should always contain the same data.
To enable the experimental SQLite support you need: 1) Airio FULL/PROS version. 2) A new library in main Airio folder, System.Data.SQLite.DLL, this file MUST always be there, even when you do not need SQLite. 3) UseSQLite set to true in the CFG file. 4) Installed native SQLite library as pointed to in the changelog. This fourth point may cause most troubles, so I'll try to look at it a bit closer.
On Windows you'll need sqlite3.dll file. You can install it directly in Airio directory or (maybe better) into Windows/system32 directory. Just copy the file there, no special installation is necessary. If you're using 500servers as your provider, the file should already be installed in the system, so you do not need to take step 4) above.
On Linux the native library is called sqlite3.so, so this file needs to be available. Unfortunately I do not use Linux so I cannot help you much concerning instructions where to put the file. My suggestion resulting from discussions with nl2dav of the CG servers: 1) Put the file into /usr/lib directory. 2) Try running Airio with SQLite support enabled. 3) See the log for any error reports and act accordingly.
Well, I know point 3) here is pretty vague, but if the system for example says it cannot find "libsqlite3.so.0", rename the original sqlite.so file and try running Airio again...
To enable the experimental SQLite support you need: 1) Airio FULL/PROS version. 2) A new library in main Airio folder, System.Data.SQLite.DLL, this file MUST always be there, even when you do not need SQLite. 3) UseSQLite set to true in the CFG file. 4) Installed native SQLite library as pointed to in the changelog. This fourth point may cause most troubles, so I'll try to look at it a bit closer.
On Windows you'll need sqlite3.dll file. You can install it directly in Airio directory or (maybe better) into Windows/system32 directory. Just copy the file there, no special installation is necessary. If you're using 500servers as your provider, the file should already be installed in the system, so you do not need to take step 4) above.
On Linux the native library is called sqlite3.so, so this file needs to be available. Unfortunately I do not use Linux so I cannot help you much concerning instructions where to put the file. My suggestion resulting from discussions with nl2dav of the CG servers: 1) Put the file into /usr/lib directory. 2) Try running Airio with SQLite support enabled. 3) See the log for any error reports and act accordingly.
Well, I know point 3) here is pretty vague, but if the system for example says it cannot find "libsqlite3.so.0", rename the original sqlite.so file and try running Airio again...
No changes in the formula for a month or two now. And I do not plan any. It is only a question of local processing and sending the correct data, and there've been changes recently (and there still may be some, to make it all as much bullet-proof as possible).
Yup, it is great the WR table is up-to-date, the problem could be that in 2.4.2 WR updates are not transfered into data sent to airio.eu for processing. I'm not absolutely sure now, but it is probable WR updates are immediatelly used only from 2.4.3. I'll be announcing 2.4.3 today, because I solved the final SQLite support problem, so stay tuned and see if you get the same LFSEI values as on CG and AA (that is when you can update). 
Hm, that would be rather weird, but not impossible. If possible, try restarting your Airio and see if that changes anything. Also WR table updates should be running (which they are, by default, if LFSW access key(s) are defined). Well, generally this dependence on local WR table is not a good thing, maybe I should be sending more general data and doing more processing remotely, at airio.eu... Ehhh...
I believe it is due to the version changes. 2.4.3 handles WR updates slightly differently, more dynamically. It uses newer, improved lap time data, and thus some PBs fall into lower category, resulting in slightly lower HL index. BTW, the new Airio version is almost ready, I need to address one more issue related to the introduction of partial SQLite support and data import to the database.
Ha! Yes, that could be a solution...
Uhm, little background first. Several months ago I was repeatedly asking developers to do or at least consider some changes I thought could be relatively simple. One of those changes was direct custom cars support, in game via specific new setups, on LFSW with new categories incorporated into the existing ones.
Only when I received no response at all I went adventurous and started the custom implementation. It was not easy for me, because I never worked with databases so I had to learn and implement everything from scratch. The big surprise is it actually works as expected.
Yes, I know what you mean. Still, the custom cars support is working quite well I think and could be extended. But to have an understandable system the new car names should be somehow obvious and meaningful. The Baby/Junior separation looks good, and I think it is better to do it earlier than later.
No name was given. It was matched to UFR, yes, but I do not remember the values now. I already asked, when I get answer I'll inform you. But overall, GTLs with over 40% restriction does not appeal much to me. With slightly over 20% it was a great car for my cheap mouse to control.
Wow, hm. Basically the core calculation is done at airio.eu, so it is the same for all FULL Airios. Local Airios only supply input data, so the difference could be a result of some data not available temporarily. Maybe your hotlaps were not downloaded properly from LFSW, and in that case incomplete data would be used for the calculation. Anyway, I just checked and it gave me exactly the same number as on AirAttack.
Yup, the stats start to be useful there. Just today I extended the chart to 24 hours and changed what servers are displayed to something more informative. I'd like to add weekly chart too, maybe, and some Airio servers stats as well...
PS: Currently supported cars table, ha... I need to make one, somehow, somewhere...
PPS: XFR had 22%, UFR then 24% (thx for info goes to babyonwheels). In the new AIRW paradigm they could be Junior-level cars, XFJ and UFJ...
Only when I received no response at all I went adventurous and started the custom implementation. It was not easy for me, because I never worked with databases so I had to learn and implement everything from scratch. The big surprise is it actually works as expected.
Yes, I know what you mean.
Still, the custom cars support is working quite well I think and could be extended. But to have an understandable system the new car names should be somehow obvious and meaningful. The Baby/Junior separation looks good, and I think it is better to do it earlier than later.No name was given. It was matched to UFR, yes, but I do not remember the values now. I already asked, when I get answer I'll inform you. But overall, GTLs with over 40% restriction does not appeal much to me. With slightly over 20% it was a great car for my cheap mouse to control.
Wow, hm. Basically the core calculation is done at airio.eu, so it is the same for all FULL Airios. Local Airios only supply input data, so the difference could be a result of some data not available temporarily. Maybe your hotlaps were not downloaded properly from LFSW, and in that case incomplete data would be used for the calculation. Anyway, I just checked and it gave me exactly the same number as on AirAttack.
Yup, the stats start to be useful there. Just today I extended the chart to 24 hours and changed what servers are displayed to something more informative. I'd like to add weekly chart too, maybe, and some Airio servers stats as well...
PS: Currently supported cars table, ha... I need to make one, somehow, somewhere...
PPS: XFR had 22%, UFR then 24% (thx for info goes to babyonwheels). In the new AIRW paradigm they could be Junior-level cars, XFJ and UFJ...
Last edited by EQ Worry, .
Wow, that is a tricky question! So, let me think while writing.
Autio and AIRW always ignore local custom car settings. They receive standard car name + applied restrictions, store the data and use it to internally assign custom car type as defined on the Web site. That means whenever you'll be using XFR with 43% restriction, AIRW will be seeing it as XFB and reporting it back as such. The back-reporting includes online AIRW messages and also world records in custom cars updated once an hour just as LFSW WRs.
Locally the PBs will be stored as XFJ. For example !sb xfb will return nothing, while !sb xfj will work as expected. On the other hand !wr xfj will return nothing or WR of XFR with lower restriction (about 20%), while !wr xfb will give you a WR of the car you call XFJ.
But then it gets yet more complicated. For the good lap times and several other things WRs are used. If there's a mismatch in custom car names, Airio would see you as joining with XFJ and will look up XFJ world record. But this XFJ would have e.g. 23% restriction and not 43%, meaning the good lap times will be impossible to achieve.
This problem arises only when AIRW and local Airio use the same car name with very different specifications. Question is it this could be solved by applying time adjustments for local XFJ in the TCD file, but that would require testing and searching in the code.
Overall conclusion? The could be specific problems, for the smoothest run it is best to have local and AIRW custom car names synchronized...
So, let me think while writing.Autio and AIRW always ignore local custom car settings. They receive standard car name + applied restrictions, store the data and use it to internally assign custom car type as defined on the Web site. That means whenever you'll be using XFR with 43% restriction, AIRW will be seeing it as XFB and reporting it back as such. The back-reporting includes online AIRW messages and also world records in custom cars updated once an hour just as LFSW WRs.
Locally the PBs will be stored as XFJ. For example !sb xfb will return nothing, while !sb xfj will work as expected. On the other hand !wr xfj will return nothing or WR of XFR with lower restriction (about 20%), while !wr xfb will give you a WR of the car you call XFJ.
But then it gets yet more complicated. For the good lap times and several other things WRs are used. If there's a mismatch in custom car names, Airio would see you as joining with XFJ and will look up XFJ world record. But this XFJ would have e.g. 23% restriction and not 43%, meaning the good lap times will be impossible to achieve.
This problem arises only when AIRW and local Airio use the same car name with very different specifications. Question is it this could be solved by applying time adjustments for local XFJ in the TCD file, but that would require testing and searching in the code.
Overall conclusion? The could be specific problems, for the smoothest run it is best to have local and AIRW custom car names synchronized...
Well, back to the above theme, having UFB and XFJ falling into the same category still sounds weird to me. I would say B stands for Baby and J for Junior. But Baby and Junior could be two different categories, Baby with restriction say something over 40%, Junior something over 20%. The other day I was racing in XFR with 23% and it was great. Personally, I'd love to call such cars Junior, so that there could be UFJ and XFJ. Cars restricted by 45 resp. 43% are in the Baby category, and UFB and XFB would be the most suitable names. This Baby/Junior separation would seem logical and understandable to me and applicable basically to all car types. XFJ is maybe a known name among those few 
who frequent it, but adjusting to a more consistent naming scheme should not be much of a problem? C'mon, it would make me happy!
who frequent it, but adjusting to a more consistent naming scheme should not be much of a problem? C'mon, it would make me happy! OK then, I'll add it in a few minutes...
Yup, there's a good chance I could.
One suggestion though: Why not call it XFB (Baby XFR), so that we have UFB and XFB, two baby GTL cars? Seems more, uhm, kind of systematic, to me... 
Closer than 15 meters for 3 seconds or more. If you turn on path check for yourself, you'll see messages when the lap is invalidated.
Indeed, TV Director, thanks for replying 2 Boothy and Illusion (not an). I'm not sure if TVD could be used when you're actually driving, but I don't think so, it is just for watching. If you need various data about race you're taking part in, check out Aonio (see my signature below). One of the configurable panels can show data about driver visually in front of you and behind you, an other one can show race laps/current lap both of the leader and yourself...
It was a design decision taken almost 2 years ago. So far nobody needed to race for more than 96 minutes using Airio...
Hm, if you look up the !len command in help screens (!l2 in this case), you'll see it support values from -96 to +96, that means maximum race length in minutes is 96. Lengths over 48 minutes are always rounded to even number, that is why 61 changes to 60. But using up to 96 should be possible. If not, it would be a bug...
Hm, I believe the numbers in Autio are OK, if you take a look at the reported online people or sum up number of people on all servers, I believe you'll get the same number that the hosts list contains. It is just sums appearing on LFSW that seem somehow strange...
The numbers are as accurate as you can get it. Every minute Autio is asking LFSW for a complete list of hosts. This list includes also all currently connected usernames, so t goes through the list (containing usually 100 to 1000 names) and updates their "last seen" field in a database table. I was using the hosts list for different purposes for a year or so now and I think it is very reliable.
The data gathering runs now just for 2 full days, there is no one seen as "last connected" more than 2 days ago, that's why the bottom table items are mostly the same. To see different numbers in the 4w column we need to wait for 4 weeks.
Hm, it works very good for me in IE and Opera...
Hm, interesting, thx for info. It seems there are currently about 80 people on hidden servers (all of them Finns, for some reason, which I'm not going to speculate about). We're still missing some 250 souls though.
FGED GREDG RDFGDR GSFDG